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Procede de controle avec gestion d'un identifiant opaque d'utiltsateur 
de la livraison complete d'un service utilisant un ensemble de serveurs 

La presents invention concerne le domaine des telecommunications 
et la gestion des services multimedia. La presente invention concerne plus 
5 particulierement un procede permettant de controler la livraison complete 
d'un service fourni via un ensemble de serveurs «enablers» et en gerant un 
identifiant opaque d'utilisateur. 

Dans tout ce qui suit, on appellera « enabler » ou « service enabler » 
tout element serveur capable de deiivrer un service. Les definitions des 
10 termes techniques d'origine anglaise utilises dans ce qui suit sont exposees 
ci-apres : 

Commit : action sur une transaction permettant de faire passer son 
etat a definitivement valide 

- Rollback : action sur une transaction en echec permettanfr^de 
15 signifier Tabandon de la transaction en cours et de repasser le 

systeme dans son etat initial * 

- Begin . action marquant le debut d'une transaction 

- TimeOut : fin du delai d'attente 

- Mask : masquer 

20 - Unmask : demasquer 

Start : demarrer 

Completed : notifier le bon achevement 
Error : notifier Terreur 
Update : mettre a jour 
25 - OpenTransaction : ouvrir la transaction 

- CloseTransaction : fermer la transaction 

. II est connu dans Tart anterieur des gestlonnaires d'identifiant (GID) 
sous la forme de systemes informatiques pourvus d'interfaces permettant de 
masquer et demasquer Tidentite d'un utilisateur a Taide d'un identifiant 
30 opaque. De tels gestionnaires GID fournissent aux systemes externes un 
riioyen de communlquer avec un utilisateur sans toutefois lui communiquer 
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son identite. Les gestionnaires d'identifiant GID sont mis en place pour des 
contraintes legates visant ^ garantir la confidentlalite de certaines 
Informations. Les GID ne sont toutefois pas adapt^s pour gerer les notions 
de session ou de transaction liees a la fois a un service et a un utilisateur ou 
groupe donnd d'utilisateurs. 

II est 6galement connu des gestionnaires de dialogue (GD) constitues 
par un systeme informatique imbrique dans un systeme de gestion de la 
facturation de services. Les gestionnaires de dialogue GD assurent d'une 
part un dialogue avec I'utilisateur pour informer celui-ci du prix d'un service 
et obtenir sa confirmation, et d'autre part le declenchement de la facturation 
a la fin d'un service. Le gestionnaire de dialogue GD est exclusivement 
oriente vers les probtemes de facturation et les mises en oeuvre d'un 
gestionnaire GD sont technologiquement dependantes de I'element serveur 
capable de creer et fournir des services « enabler ». 

II existe aussi des gestionnaires d'offre (GO) servant d verifier le bon 
deroulement de I'offre de service. Les GO sont pour la plupart 
technologiquement dependants de I'etement serveur capable de creer et 
fournir des services « enabler ». lis sont done souvent «mono-element 
serveur» voire mono-requete. lis ne sont done pas capables de traiter le bon 
deroulement d'un service «multi-elements serveurs» de bout en bout. 

II est connu par ailleurs des plates-formes logicielles « frameworks » 
de developpement de service, qui fournissent en general un acces controle 
aux ressources du reseau de I'operateur a des partenalres. Ces partenaires 
peuvent etre des fournisseurs de services a valeur ajoutee VASP (de 
I'anglais Value Added Service Provider). Les plates-formes OSA (Open 
Sen/ice Architecture) ou PARLAY sont des exemples de telles plate-formes 
« frameworks ». OSA permet ainsi de definir une interface avec un reseau 
de radiotelephonie mobile qui offre des capacites standard. PARLAY est 
comparable a OSA mais pour le reseau fixe de telephonie. De telles plate- 
formes de developpement de services fonctionnent : 

soit en mode proxy, ce qui impose une integration technique 
de la plate-forme logicielle « framework » par les partenaires 
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fournisseurs de services a valeur ajoute VASP et en outre 
une remise a jour de la plate-forme iogicielle « framework » 
pour y integrer de nouveaux elements serveurs « enablers » 
capables de creer et fournir des services ou simplement de 
nouvelles interfaces sur des elements serveurs capables de 
cr6er et fournir des services « existants », 
soit en mode repertoire « directory » ce qui implique qu'une 
fois la reference allouee sur Telement serveur capable de 
creer et fournir des services « enabler » par la plate-forme 
Iogicielle « framework », plus aucune information statistique 
ne passe par lui. 

II n'existe done pas de solution actuelle susceptible de pouvoir assurer 
la gestion d*une session de service a un .abonne qui utilise plusieiirs 
elements serveurs « enablers » du reseau de I'operateur ; de^ 
telecommunication. II n'est alors pas possible de generer des evenements. - 
sur la complete (ou incomplete) realisation du service. 

Un objet de la presente invention est de supprimer ces inconvenients 
de Tart anterieur. Ainsi, I'invention decrite dans ce document fournit une 
solution permettant d'adresser les problematiques suivantes: 

Tassurance de la bonne livraison d'un service utilisant les . 
elements serveurs « enablers » d'un reseau operateur, 
la garantie de la QoS (Qualite de Service) de bout en bout, 
le controle de Tacces aux elements serveurs « enablers » 
. pour un utilisateur et un service donne, 
Tobtention des informations statistiques sur Tutilisation et la 
realisation d'un service aussi bien en mode Pull/MO (Mobile 
Originated) provenant d'une requete du mobile qu'en mode 
Push/MT (Mobile Terminated) provenant d'une requete d'un 
element serveur a destination d'un mobile, 
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la gestion des identifiants opaques qui permet a Toperateur 
de garantir la confidentialite de Tutiiisateur vis-a-vis des 
fournisseurs de service. 
A cet effet, Tinvention concerne un precede de controle avec gestion 
d'un identifiant opaque d'utilisateur de la livraison complete d'un service 
utillsant au moins un serveur, caracterise en ce qu'il est realise par 
Tinternnediaire d'un moyen serveur d'identifiant transactionnel stockant dans 
une memoire pour cheque utilisateur une description d'une pluralite d'offres 
de service souscrite par Tutiiisateur aupres des fournisseurs de service, ledit 
moyen sen/eur d'identifiant transactionnel comprenant un module de gestion 
permettant d'associer a un utilisateur ou groupe d'utilisateurs et a au moins 
un service determine un identifiant transactionnel opaque, ledit precede 
comprenant les etapes suivantes : 

emission par un element serveur « enabler» ayant intercepts une 
demande de service d'un utilisateur ou par un desdits fournisseurs 
de service d'une requete d'ouverture de transaction d'au moins un 
service faisant appel a au moins un element serveur « enabler » 
determine realisant des sous-transactions, cette requete etant 
decrite de maniere sequentielle avec un lot de primitives ouvertes 
et adressee a une interface de communication du moyen serveur 
d'identifiant transactionnel et notifiant une identification de 
I'utilisateur, 

analyse de la requete et generation d'un identifiant transactionnel 
opaque par des moyens de gestion et de controle du sen/eur 
d'identifiant transactionnel, puis 

une etape de realisation de la transaction utilisant I'identifiant 

transactionnel opaque, 
^invention permet done permet d'acceder a I'offre d'un service tout en 
garantissant la confidentialite de Tutilisateur vis-a-vis des fournisseurs de 
service, par utilisation d*un identifiant opaque de session pour un utilisateur 
autorise. 
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Selon une autre particularite de Tinvention, Tetape d'analyse 
comprend une verification par le module de gestion de la correspondance 
des elements serveurs « enablers » determines avec une offre de service 
repertoriee accessible pour Tutilisateur parmi la pluralite d'offres de service 
5 et un controle de Tautorisation d'ouverture de la transaction par des moyens 
de controle du moyen serveur d'identifiant transactionnel, pour le service 
fourni par les elements serveurs « enablers » et Tutilisateur specifie, en 
fonction notamment de INdentification de rutilisateur. 

Selon une autre particularite de Tinvention, Tetape de realisation de la 

10 transaction est initiee par un fournisseur de service a valeur ajoutee ayant 
regu Udentifiant transactionnel opaque de la part du moyen serveur 
d'identifiant transactionnel, le fournisseur d'offres de service effectuant une 
demande a un element serveur enabler determine, avec Tidentifiant 
transactionnel opaque en parametre, d'un service determine constituant une** 

15 sous-transaction, pour declencher en reponse sur I'element serveur enabler 
determine renvoi vers le serveur d'identifiant transactionnel d'une requete de 
demasquage « unmask » permettant a partir de Tidentifiant opaque la 
fourniture d'un numero d'identification non opaque correspondent a 
I'identifiant transactionnel opaque, un controle etant ensuite realise par les 

20 moyens de controle du moyen serveur d'identifiant transactionnel pour 
verifier si Telement serveur determine « enabler» est autorise ou non pour ce 
service et pour cet utilisateur, de sorte qu'en cas d'autorisation, le numero 
d'identification non opaque (MS-ISDN) est transmis via une interface de 
communication dite interface enabler vers Telement serveur determine pour 

25 permettre la realisation de la sous-transaction, 

Selon une autre particularite de Tinvention, I'identifiant transactionnel, 
est compose d'au maximum 15 digits, et conforme au plan de numerotation 
UIT-T E-164 et le numero d'identification non opaque est le numero MSISDN 
(Mobile Station integrated Services Digital Network). 

30 Selon une autre particularite de invention, le moyen serveur 

d'identifiant transactionnel (GIDT) comporte, d'une part un moteur 
transactionnel generant des emissions d'evenements transactionnels 
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constitues de Tune ou Tautre des commandes suivantes : BEGIN, COMMIT, 
ROLLBACK et d'autre part d'un moteur de tragabilite consignant dans ladite 
memoire chaque evenement du moteur transactionnel et Tensemble des 
informations emises pendant I'utilisation du moyen sen/eur d'identifiant 
transactionnel. 

Selon une autre particularite de {'invention, i'identifiant transactionnel 
opaque est envoye au fournisseur d'offres de service apres la memorisation 
dans la memoire du moyen sen/eur d'identifiant transactionnel, d'un contexte 
transactionnel indiquant notamment : 

le numero didentification de I'utilisateur, 

ridentifiant transactionnel, 

Toffre associee a la transaction, 

I'etat d'avancement de la transaction pour Toffre associee a ceile-ci 
(nombre de sous-transactions achevees, sous-transactions restant 
a executer,..,). 

Selon une autre particularite de IMnvention, I'envoi de ridentifiant 
transactionnel opaque au fournisseur d'offres de sen/ice est precede en 
outre d'une generation d'un evenement transactionnel representatif d'un 
debut de transaction vers au moins un systeme externe, par I'intermediaire 
d'une seconde interface de communication du moyen serveur d'identifiant 
transactionnel, dite interface de notification des transactions. 

Selon une autre particularite de Tinvention, la generation d'un 
evenement transactionnel representatif d'un debut de transaction vers au 
moins un systeme externe s'effectue par une commande BEGIN generee 
par un moteur transactionnel du moyen serveur d'identifiant transactionnel. 

Selon une autre particularite de I'invention, le moyen serveur 
d'identifiant transactionnel transmet, depuis I'interface de notification des 
transactions a au moins un systeme externe, des donnees representatives 
de la realisation complete de I'offre par une commande COMMIT generee 
par le moteur transactionnel pour indiquer au systeme externe par exemple 
de facturation que la transaction est completement reaiisee. 
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Selon une autre particularite de invention, le moyen serveur 
d'identifiant transaction nel, emet, via Tinterface de notification des 
transactions, un evenement transactionnel de type fin de reprise ROLLBACK 
pour signifier a au nnoins un systeme externe que le nombre de reprises de 
5 la transaction sur erreur est depasse et que la transaction est annulee pour 
fo.urnir des donnees a un gestionnaire de dialogue et pour facturer ou non le 
service. 

Selon une autre particularite de Tinvention, les moyens de gestion et 
de controle du serveur d'identifiant transactionnel effectuent Tanalyse de la 

10 requete d'ouverture de transaction notamment par resolution d'une 
correspondance entre une adresse technique de service notifiee dans la 
requete d'ouverture de transaction et une offre de service repertoriee parmi 
la pluralite de descriptions d'offres de service. stockees dans la memoire du 
moyen serveur d'identifiant transactionnel. .^y.^ 

15 Selon une autre particularite de Tinvention, la memoire du moyen 

serveur d'identifiant transactionnel stocke des descriptions d'offres^;.de 
service validees par lesdits fournisseurs, saisies par Tintermediaire d'une 
troisieme interface de communication dite interface de fourniture des 
descriptions de sen/ice. 

20 Selon une autre particularite de Tinvention, la description d'une offre 

de service comprend des donnees formulees dans un meta langage ou 
forme equivalente permettant aux moyens de controle du moyen serveur 
d'identifiant transactionnel de controler le bon deroulement du service et d'en 
detecter le debut et la fin. 

25 Selon une autre particularite de invention, le moyen serveur 

d'identifiant transactionnel comporte une interface de communication 
supplementaire destinee aux fournisseurs dei services a vaieur ajoutee, la 
premiere interface etant destinee aux elements serveurs. 

Selon une autre particularite de Tinvention, le moyen serveur 

30 d'identifiant transactionnel comporte une logique interne realisant les 
methodes suivantes : Start, Completed. Error, Mask, Unmask, Update, 
OpenTransaction. CloseTransaction. 
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Selon une autre particularite de I'invention, la methode Start du 
moyen serveur d'identifiant transactionnel genere un identifiant 
transactionnel, cree un contexte transactionnel en memoire, genere un 
evenement transactionnel de type BEGIN et retourne Tidentifiant 
5 transactionnel au fournisseur d'offres de service. 

Selon une autre particularite de Tinvention, la methode Completed du 
moyen serveur d'identifiant transactionnel determine par un test si une sous- 
transaction de la transaction a ete realisee, modifie en consequence le 
contexte transactionnel, determine, en scrutant la description de I'offre sMI 
10 est necessaire que le moyen serveur d'identifiant transactionnel attende un 
evenement exterieur, positionne la logique soit en attente d'un temps ecoule 
« TimeOut » soit d'une fermeture de transaction « CloseTransaction », 
verifie si la transaction est achevee et genere un evenement transactionnel 
de type COMMIT. 

15 Selon une autre particularite de Tinvention, la methode Error du 

moyen serveur d'identifiant transactionnel verifie si le nombre de reprise sur 
erreur est depasse et dans Tafflrmative genere un evenement transactionnel 
de type ROLLBACK. 

Selon une autre particularite de Tinvention, la methode Mask est 

20 emise par un element serveur « enabler » pour retrouver les informations de 
Toffre ciblee a pari:ir de Tadresse technique et de ladite pluralite d'offres, 
controler Tacces d'un utilisateur abonne a I'offre de service et emettre soit un 
refus d'acces soit declencher la methode Start. 

Selon une autre particularite de I'invention, la methode Unmask est 

25 emise par un element serveur « enabler » pour retrouver les informations de 
I'offre ciblee a partir de donnees representatives de Tadresse technique et 
I'identifiant transactionnel (trid) et a partir du catalogue des offres, controler 
I'acces d'un fournisseur partenaire a Telement serveur « enabler », verifier 
que la requete faite a Telement serveur est en correspondance avec I'etat 

30 actuel de la transaction et signaler ^ I'element serveur que le moyen serveur 
d'identifiant transactionnel est en attente d'une mise a jour, retourner le 
MSISDN associe a I'identifiant transactionnel opaque, se mettre en attente 
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de la mise a jour, puis verifier que la mise a jour regue contient les 
informations necessaires pour la realisation de Toffre pour soit emettre une 
methode Completed soit une methode Error. 

Selon une autre particularite de Tinvention, la methode Update est 
5 emise par un element serveur « enabler » et constltuee par la mise en etat 
d'attente de mise a jour concernant la realisation de la requete du serveur 
didentifiant transactionnel. 

Selon une autre particularite de Tinvention, la methode 
OpenTransaction est emise par un fournisseur de services a valeur ajoutee 
10 pour controler I'acces d'un partenaire a un abonne de i'operateur et produire 
soit un refus d'acces soit declencher une methode Start. 

Selon une autre particularite de invention, la methode 
CloseTransaction est emise par un fournisseur de services a valeur ajoutee 
et genere un evenement permettant de debloquer Tattente « TimeOut » de la 
15 logique du moyen serveur d'identifiant transactionnel, > 
L'invention, avec ses caracteristiques et avantages, ressortira plus 
clairement a la lecture de la description faite en reference aux dessins 
annexes donnes a titre d'exemples non limitatifs dans lesquels : 

la figure 1 represente schematiquement un exemple de processus 
20 mis en oeuvre dans Tinvention, dans une variante en mode 

Push/MT, / : 

la figure 2 represente de maniere schematique un moyen serveur 
d'identifiant utilise dans I'invention, 

la figure 3 represente trois elements de logique utilises par le 
25 moyen sen/eur d'identifiant, 

la figure 4 represente des schemas de logiques d'etats associees 
aux interactions entre les elements serveurs « enablers » du 
reseau et le moyen serveur d'identifiant, 

la figure 5 represente un exemple de logiques d'etat associees aux 
30 interactions entre des fournisseurs de service a valeur ajoutee et le 

moyen serveur d'identifiant, 
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de la mise a jour, puis verifier que la mise a jour rfegue contient les 
informations necessaires pour la realisation de I'offre pour soit emettre une 
methode Completed soit une methode Error. 

Selon une autre particularite de I'invention, la methode Update est 
emise par un Element serveur « enabler » et constituee oar la mise en etat 
d'attente de mise a jour concernant la realisation de la requete du serveur 
d'identifiant transactionnel. 

Selon une autre particularite de I'invention, la methode 
OpenTransaction est emise par un fournisseur de services ^ valeur ajoutee 
pour controler I'acces d'un partenaire a un abonne de I'opfjrateur et produire 
soit un refus d'acces soit declencher une methode Start. 

Selon une autre particularite de I'invention. la methode 
CloseTransaction est emise par un fournisseur de services a valeur ajoutee 



« TimeOut » de la 



et g6n6re un 6v6nement permettant de debloquer I'attente 

logique du moyen serveur d'identifiant transactionnel. 

L'invention, avec ses caracteristiques et avantages, ressortira plus 

clairement a la lecture de la description faite en reference aux dessins 

annexes donnes a titre d'exemples non limitatifs dans lesquels : 

la figure 1 represente schematiquement un exenple de processus 
mis en ceuvre dans I'invention, dans une variante en mode 
Push/MT, 

la figure 2 represente trois elements de logique utilises par le 
moyen serveur d'identifiant, 
la figure 3 represente des schemas de logiques 
aux interactions entre les elements sen/eurs 
reseau et le moyen serveur d'identifiant, 
la figure 4 represente un exemple de logiques d'ljtat associ^es aux 
interactions entre des fournlsseurs de service a valeur ajout6e et le 
moyen serveur d'identifiant, 



d'etats associees 
« enablers » du 
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la figure 6 represente schematiquement un exemple de processus 
mis en oeuvre dans Tinvention, dans une variante en mode 
Pull/MO. De plus, Tannexe precise les abreviations utilisees dans 
la presente demande, 

5 

L'invention va a present etre decrite en liaison avec les figures 1 a 3. 
Le precede selon invention est realise par Tintermediaire d'un moyen 
serveur d'identifiant transactionnel qu'on appellera par la suite gestionnaire 
d'identifiant transactionnel (GIDT). Ce moyen serveur d'identifiant (GIDT) 

10 permet d'associer un element d'identification (Userld) correspondant a un 
utilisateur (ou un groupe d'utilisateurs) pour une transaction ou une sous- 
transaction sur un service donne. Get identifiant transactionnel (trld) est 
utilise en substitution du numero MS-ISDN. (Mobile Station - Integrated 
Services Digital Network) dans la communication avec les fournisseurs:de 

15 service partenaires (33) tels que VASP, fournisseurs d'applications-.et 
portails specialises ou autres partenaires et a pour caracteristique d'.etre 
conforme a la recommandation d*un plan de numerotation normalise, par 
exemple UIT - T E.164, ce qui impose une sequence d'au maximum 15 digits 
dont une partie de Tinformation peut permettre d'identifier Toperateur 

20 susceptible d' interpreter cet identifiant transactionnel (trld). Le gestionnaire 
d'identifiant transactionnel (GIDT) comprend une premiere interface (21) de 
communication pour permettre la transmission de donnees avec des 
serveurs ou enablers (31). Ce gestionnaire (GIDT) comprend en outre une 
seconde interface (22) de communication, dite interface de notification des 

25 transactions, permettant la generation d'evenements transactionnels 
representatifs d'un debut (ST), d'une finalisation (CT) ou d'une annulation 
(ET) de transaction vers n'importe quel systeme externe (40). Cette interface 
(22) permet par exemple de relier le gestionnaire (GIDT) a un ou plusieurs 
systemes externes (40) de facturation et/ou a un gestionnaire de dialogue. 

30 Comme represente a la figure 1, le gestionnaire d'identifiant 

transactionnel (GIDT) comprend un module de gestion (27) permettant 
d'associer a un utilisateur ou groupe d'utilisateurs et a au moins un service 
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la figure 5 represents sch6matiquement un exernple de processus 
mis en CBuvre dans I'lnventlon. dans une variants en mode 
Pull/MO. De plus, rannexe precise les abr6viations utiiisees dans 
la presents dennande. 



L'invention va a present etre decrite en liaison avec 



Le precede seion l'invention est realise par I'intermediaire d'un moyen 



es figures 1 et 2. 



suite gestionnaire 
identifiant (GIDT) 



serveur d'identifiant transactionnel qu'on appellera par la 
d'identifiant transactionnel (GIDT). Ce moyen serveur d 
permet d'associer un element d'identification (Userld) ccrrespondant^ un 
utilisateur (ou un groupe d'utilisateurs) pour une transac ion ou une sous- 
transaction sur un service donne. Get Identifiant transJctionnel (trid) est 
utilise en substitution du numero MS-ISDN (Mobile Station - Integrated 
Services Digital Network) dans la communication avec iJs foumisseurs de 
service partenaires (33) tels que VASP, foumisseurs , d'applications et 
portails specialises ou autres partenaires et a pour carLcteristique d'etre 
conforme a la recommandation d'un plan de numerotatlln normalise, par 
exemple UIT - T E.164, ce qui impose une sequence d'au Maximum 15 digits 
dont une partie de I'information peut permettre d'idJntifier Toperateur 
susceptible d'interpreter cet identifiant transactionnel (trId). Le gestionnaire 
d'identifiant transactionnel (GIDT) comprend une premiere interface (21) de 
communication pour permettre la transmission de donn6es avec des 
serveurs ou enablers (31). Ce gestionnaire (GIDT) compJend en outre une 
seconde interface (22) de communication, dite interface de notification des 
transactions, pennettant la generation d'ev6nements transactionnels 



d'une annulatlon 



representatifs d'un d^but (ST), d'une finalisation (CT) ou 
(ET) de transaction vers n'importe quel systeme exteme (40). Cette interface 
(22) permet par exemple de reller le gestionnaire (GIDT) a un ou plusieurs 
systemes extemes (40) de facturation et/ou a un gestionnaire de dialogue. 

Comme represents a la figure 1, le gestionnaire d'identifiant 
transactionnel (GIDT) comprend un module de gestion (27) permettant 
d'associer a un utilisateur ou groupe d'utilisateurs et a au moins un service 



1 er depot Modifiee le 1 1 /08/03 

11 



determine un identifiant dit transactionnel (trld). Le gestionnaire (GIDT) peut 
par exemple gerer rabonnement des utilisateurs a des offres de service 
aupres des fournisseurs de service (33). En variante, le gestionnaire 
d'identifiant transactionnel (GIDT) peut aussi se connecter a un gestionnaire 
5 des abonnements. La memoire (25) du gestionnaire (GIDT) permet 
nptamment de memoriser des descriptions d'offres de service validees par 
las fournisseurs (31), et de stocker une pluraiite de contextes transactionnels 
relatifs a un utilisateur ou groupe d'utilisateur pour un service. Cliaque 
contexte transactionnel indique notamment le numero d'identification 
10 (Userld) de Tutilisateur, I'identifiant transactionnel (trld), Toffre associee a la 
transaction et Tetat d'avancement de la transaction. Get etat d'avancement 
peut etre decrit par exemple par le nombre de sous-transactions (R') 
achevees, de sous-transactions (R*) restant a executer. Les descriptions 
d'offres de service peuvent etre saisies par un systeme d'approvisionnement 
15 (32) avec une troisieme interface de communication dite interface/ Tde 
fourniture des descriptions de service (IFDS). 

Comme represents a la figure 2, le gestionnaire d'identifiant 
transactionnel (GIDT) peut se placer au coeur d'une plate-forme logicielle 
susceptible de : 
20 - gerer les identifiants transactionnels (trld), 

gerer les informations statistiques des acces aux requetes de 
demasquage paries enablers (31) du reseau, 
stocker une representation du service, et plus particulierement son 
sequencement/deroulement, 
25 - controler le deroulement d'un service et done s'assurer de sa 
realisation de bout en bout, 

emettre des triggers transactionnels, par exemple BEGIN (ST) 
pour commencer, COMMIT (CT) pour executer. ROLLBACK (ET) 
pour annuler (figure 3). 
30 Pour parvenir a gerer les identifiants transactionnels (trld), le module 

de gestion (27) est relie a la memoire (25) et a ['interface de fourniture des 
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determine un identifiant dit transactionnel (trid). Le gestionnaire (GIDT) peut 



offres de service 



par exemple gerer I'abonnement des utilisateurs S des 
aupr^s des foumisseuns de service (33). En variante, le gestionnaire 
d'Identifiant transactionnel (GIDT) peut aussi se connecter* a un gestionnaire 
des abonnements. La m^moire (25) du gestionnaire (GIDT) permet 
notamment de memoriser des descriptions d'offres de service validees par 
les fournlsseurs (31), et de stocker une pluralite de contexJes transaction nels 
relatifs a un utilisateur ou groupe d'utilisateur pour un service. Chaque 
contexte transactionnel indique notamment le num6ro d'identification 
(Userld) de I'utilisateur, I'ldentifiant transactionnel (trId), I'iffre associee a la 
transaction et Tetat d'avancement de la transaction. Get itat d'avancement 



peut etre decrit par exemple par le nombre de sous 
achevees. de sous-transactions (R') restant a executer. 



d'offres de service peuvent etre saisies par un systeme d'approvisionnement 



-transactions (R') 
Les descriptions 



dite interface de 



forme logicielle 



aux requites de 



(32) avec une trolsfeme interface de communication 
fourniture des descriptions de sen/ice (IFDS). 

Comme repr6sente a la figure 1. le gestionLire d'identifiant 
transactionnel (GIDT) peut se placer au cceur d'une plate-; 
susceptible de : 

gerer les identifiants transactionnels (trId), 
gerer les informations statistiques des acces 
d6masquage par les enablers (31) du reseau, 
stocker une representation du sen/ice, et plus particulierement son 
sequencement/deroulement, 
controler le d6roulement d'un service et done 
realisation de bout en bout, 
emettre des triggers transactionnels, par exemple BEGIN (ST) 
pour commencer, COMMIT (CT) pour executer, 
pour annuler (figure 2). 
Pour parvenir ^ gerer les identifiants transactionnels (trId), le module 
de gestion (27) est relie a la memoire (25) et a I'interface de fourniture des 



s'assurer de sa 



ROLLBACK (ET) 
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descriptions de service (IFDS). Dans un mode de realisation de I'invention, la 
memoire (25) du gestionnaire d'identifiant transactionnel (GIDT) stocke des 
descriptions d'offres de service transmises par le systeme 
d'approvisionnement (32) en descriptions de service qui utilise Tinterface de 
5 fourniture (IFDS). Ce systeme d'approvisionnement (32), dont tiennent 
compte les fournisseurs partenaires (33), permet de fournir une description 
complete d'un service. Dans un mode de realisation de I'invention, la 
memoire (25) stocke des descriptions detaillant les services, notamment le 
mode de communication avec les elements enablers (LOG, SMS, MMS) qui 

10 font partie de I'offre. Cette description pourrait etre definie a partir d'un meta 
langage, Expression Reguliere, XML Schema ou DTD par exemple, ou sous 
tout autre forme permettant au gestionnaire d'identifiant transactionnel 
(GIDT) de controler le bon deroulement d'un service et d'en detecter le debut 
et la fin. Les fournisseurs partenaires (33) ont connaissance du mode/vde 

15 description de leur service, de telle sorte qu'une offre correspondant MJa 
description attendue, incluant un ou plusieurs services, peut etre 
effectivement realisee. 

Par exemple dans le cas d'une offre de service faisant intervenir un 
enabler de localisation (LOG), un enabler de messages courts (SMS) et un 

20 enabler de messages multimedia (MMS), la description du service peut se 
presenter sous la forme suivante : « (SMS_MO, LOG, MMS) ». c'est-a-dire 
que le service complet doit etre compose d'un SMS_MO, d'une demande de 
localisation et de renvoi d'un message multimedia. Dans un autre exemple, 
la description peut etre formulee comme suit : « (LOG, WAP-PUSH+, [close- 

25 transaction|timeout(2 jours)]) », ce qui signifie que le sen/ice doit etre 
compose d'une demande de localisation, suivie de 1 a n push WAP. La fin 
de service est declenchee soit sur un delai d'attente dit timeout, soit par un 
ordre de fermeture de transaction dit close-transaction explicite d'un serveur 
enabler (31) ou du fournisseur de service (33). 

30 La description de service peut aussi detainer le contenu de chaque 

requete a un element serveur enabler (31) comme par exemple 
« (SMS_MO:'^BLAGUE*',MMS) », pour signifier que le sen/ice doit etre 
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compose d'un SMS_MO commeriQant par BLAGUE et d'un message 
multimedia. Dans une varlante de realisation de I'invention, la description du 
service peut eventuellement incorporer des sous-parties transactionnelles, 
susceptibles par exemple d'etre d6finies comme imbriquees. Ainsi, dans le 
cas d'une description XML, les mecanismes d'import ou de reference 
peuvent etre utilises. Dans ce cas-la, la realisation d'un service peut etre 
conditionnee par la realisation de sous-parties transactionnelles. Ces 
demieres sont eventuellement facturees separement par un systeme externe 
(40) de facturation. Les serveurs enablers (LOG, SMS, MMS) de la figure 1 
ne sont cites qu'a titre d'exemple. N'importe quel autre element serveur 
enabler comme CAMEL. WAP-server, etc. peut etre utilis6 dans le 
processus mis en ceuvre avec le gestionnaire d'identifiant transactionnel 
(GIDT). 

Dans un mode de realisation de {'invention, le moyen serveur 
d'identifiant transactionnel (GIDT) comporte .une interface de communication 
suppiementaire (23) destinee aux foumisseurs de service a valeur ajoutee 
(33)ou equivalent, la premiere interface (21) 6tant destinee aux aux 
elements serveurs (LOG, SMS, MMS) du reseau. Gette interface 
supplementaire (23) permet a un fournisseur partenaire (33) d'ouvrir une 
transaction pour un utilisateur donne sur un type de service. Gette interface 
(23) n'est necessaire que dans le cas ou un fournisseur de service (33) initie 
le service vers I'abonne, c'est-a-dire en mode PUSH, comme dans la forme 
de realisation de la figure 1 par exemple. Dans le cas d'une description de 
sen/ice ouverte, le fournisseur partenaire (33) de type VASP ou analogue 
peut avoir a sa disposition une methode lui permettant de signifier que le 
service a, selon lui, ete realise. Par aiileurs, cette interface supplementaire 
(23) etant optionnelle, le gestionnaire (GIDT) constitue dans la plupart des 
cas un composant transparent pour les partenaires VASP ou partenaires 
analogues. 

L'invention va S present etre decrite en liaison avec la figure 3. 
La figure 3 presente trois elements de logique d'une logique interne 
utilisee par le module de gestion (27) pour gerer avec un identiflant 
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compose d'un SMS_MO commengant par BLAGUE 



multimedia. Dans une variante de realisation de {'invention, ia description du 
service peut eventuellement incorporer des sous-parties transactionnelles, 
susceptibles par exemple d'§tre d6finies comma imbriquees. Ainsi. dans le 



et d'un message 



cas d'une description XML, les mecanismes d'import 
peuvent etre utilises. Dans ce cas-la, la realisation d'un 



condltionnee par la realisation de sous-parties transactionnelles. Ces 



n systeme externe 



ou de reference 
service peut etre 



dernieres sont eventuellement facturees separement par ur 
(40) de facturation. Les serveurs enablers (LOG, SMS, MVIS) de la figure 1 
ne sont cites qu'a titre d'exemple. N importe quel autre element serveur 
enabler comme CAMEL, WAP-sery/er, etc. peut etr€! utilise dans le 
processus mis en ceuvre avec le gestionnaire d'identifi ant transactionnel 
(GIDT). 

Dans un mode de realisation de I'invention, 16 moyen serveur 
d'identifiant transactionnel (GIDT) comporte une interface de commuriic'ation 
supplementaire (23) destinee aux fournisseurs de servici a valeur ajdutee 
(33) ou equivalent, la premiere interface (21) etant destinee aux elements 
serveurs (LOG, SMS, MMS) du reseau. Gette interface suf 
permet a un fournisseur partenaire (33) d'ouvrir une trai 
utilisateur donne sur un type de service. Gette interface (23) n'est nece^^aire 
que dans le cas ou un fournisseur de service (33) Initio le sen/ice vers 
I'abonne, c'est-a-dire en mode PUSH, comme dans la foime de realisation 
de la figure 1 par exemple. Dans le cas d'une description de sen/ice ouverte, 
le fournisseur partenaire (33) de type VASP ou analogui peut avoir ^ sa 
disposition une methode lul permettant de signifier que le s srvice a, selon lui, 
ete realise. Par ailleurs, cette interface supplementaire (23) etant optionnelle, 
le gestionnaire (GIDT) constitue dans la plupart des c£is un composant 
transparent pour les partenaires VASP ou partenaires analogues. 

L'invention va a present etre decrite en liaison avec la figure 2. 

La figure 2 presente trois elements de logique d'ure logique interne 
utilisee par le module de gestion (27) pour gerer avec un identifiant 



pplementaire (23) 
nsaction pdiir^ un 
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transactionnel (trid) opaque d'utilisateur la livraison complete du service, 
selon le processus de I'lnventlon. Parmi les trois methodes realisees par 
cette logique Interne, la m§thode appelee communement START (S) 
execute successivement les operations sulvantes, apres recuperation 
prealable (SO) du numero d'Identlflcatlon (Userld) MSISDN : 

generation (31) d'un identifiant transactionnel d'apres les donnees 

fournies, dent notamment le numero MSISDN, 

creation (S2) d'un contexte transactionnel comprenant le numero 

d'identification (Userld) MSIDSN, ('identifiant transactionnel (trId), 

I'offre assoclee a la transaction et I'etat d'avancement de la 

transaction, 

stockage du contexte transactionnel dans la memoire (25) du 
gestionnaire (GIDT), 

generation d'un evenement transactionnel BEGIN (ST) envoye 
vers les systemes externes (40) pour notlfler le debut de la 
transaction, puis, 

envoi (3) par le gestionnaire d'identlfiant transactionnel (GIDT) au 
fournlsseur de service (31) de I'ldentlfiant de transaction (trId) 
correspondant au service. 
La methode appelee communement Completed (C) du moyen serveur 
d'identlfiant transactionnel (GIDT) determine par un test (C1) si une sous- 
transaction de la transaction a ete completement realisee (CO), puis modifie 
(C2) en consequence le contexte transactionnel. De plus, la methode 
Completed (C) determine, en scrutant la description de I'offre (C3) s'il est 
necessaire que le moyen serveur d'identlfiant transactionnel (GIDT) attende 
(C5) un evenement exterieur, posltionne la logique soit en attente d'un 
temps ecoule « TimeOut » soit . d'une fermeture de transaction 
« CloseTransaction ». Enfin, cette methode permet de verifier (C4) si la 
transaction est achevee et de generer un ev6nement transactionnel de type 
COMMIT (CT). On comprend que I'element de logique correspondant a la 
methode COMPLETED (C) permet d'effectuer un controle de revolution de 
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la transaction. Plusieurs sous-transactions (R') peuvent etre successivement 
realisees au sein d'une meme transaction avec cette methode. Dans le 
mode de realisation de la figure 3, la methode COMPLETED (C) comprend 
ainsi les operations suivantes : 

eventuellement, test de controle (CI) de fin de realisation (CO) 
d'une sous-transaction (R'), et modification (C2) de Tetat 
d'avancement de la transaction memorise dans le contexte 
transactionnel en y integrant la sous-transaction (R') realisee, 
scrutation de la description de Toffre (C3) pour determiner s'il est 
necessaire que le gestionnaire (GIDT) attende un evenement 
exterieur, 

dans un premier cas, positionnement de la logique en attente (C5) 
d'un evenement, cette attente s'achevant a Tissue d'un delai 
« TimeOut » ou d'une fermeture de transaction « Close- 
Transaction », sinon, si aucun evenement particulier n'est attenjlu, 
verification (C4) de Tetat d'avancement de la transaction, puis \ 
generation d'un evenement transactionnel COMMIT (CT) envoye 
vers les systemes externes (40) pour notifier la fin de la sous- 
transaction. 

Le gestionnaire d'identifiant transactionnel (GIDT) peut transmettre, 
depuis I'interface de notification des transactions (22) vers n'importe quel 
systeme externe . (40), des donnees representatives de la complete 
realisation d'un service par la commande COMMIT (CT) generee par le 
moteur transactionnel (28) pour indiquer au systeme externe (40) par 
exemple de facturation que la transaction est completement realisee. Le 
gestionnaire (GITD) memorise en outre dans la memoire (25) cette evolution 
du contexte transactionnel, L'etape de verification (C4) permet notamment 
de faire la difference entre la fin de la toute derniere, sous-transaction (R') et 
la fin d'une sous-transaction (R') intermediaire. L'etat d'avancement de la 
realisation de la transaction peut done etre determine. 
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methode. Dans fe 



la transaction. Plusieure sous-transactions (R') peuvent e 
.^ansees au se,n d-une n,«™ .,ansao«on avec oene ,„„.,„„e. uans ,e 
mode de r^aliaatton de ,a figure 2. ,a ...hode COMPLETED (C, co^pr^nd 
amsiles operations suivantes: ; ™mprend 

- eventueilement, test de oontreie (C1) de fin 1 realisation (CO) 
dune sous-transaction (R), et modiflcatioi (C2) de f^ta 
davancemen, de ,a transaction m^^ris^ Ls te contexte 
transactionnel en y integrant la sous-transacHon [r') rtelisAe 



determiner s'il est 



scrutation de la description de I'offre (C3) pour 

necessaire que le gestlonnaire (GIDT) attence un '"^^'nemrnt 

exterieur, 

- dans un premier cas, positionnement de ia logique en attente (C5) 
dun evenement, cette attente s'achevant S 'issue dun delai 
« Timeout,, ou d'une femieture de transaction „ Ciose- 
Transacfton », sinon, si aucun ^v^nement particQlier n est attendu 
venflcation (04) de r.tat d'avancement de la tranlaction puis ' 

- generation d'un ev^nement transactionnel COMMIT (CT) envoy* 
vers les syst^mes extemes (40) pour notifler la fin de la sous- 
transaction. 

depuls'ZT'n" Ut transmet^.. 



sys^me externe (40), des donn^es representatives de la complete 
real,sat,on d un service par ,a commande COMMIT (CT generee pan! 
n^oteur transactionnel (2S) pour indlquer au system'e el:eT4oTp 
example de faCuration ,ue ,a transaction est compietemen, realise Le 
gestionnaire (GITD) memoHse en outre dans ,a memoire (2I, ce«e evo ution 

de fa,re la difference entre ia fin de la toute demiere sous-.ransacion (R') e, 
la in d'une sous-transaction (R, inten^ediaire. L'etat d avancemen. de ^ 
realisation de la transaction peu. done «t,e detem,ine 
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La logique interne du moyen serveur d'identifiant transactionnel 
(GIDT) realise egalement une methode connmunennent appelee ERROR (E) 
qui permet de detecter et de signaler la presence d'erreur ayant une 
incidence dans le processus selon Tinvention. Un code d*erreur (EO) est regu 
5 par un moyen comparateur verifiant le nombre de reprises sur erreur. Une 
comparaison (E1) est effectuee entre le nombre de reprises sur erreur at un 
seuil predetermine. Tant que le seuil n'est pas atteint, Terreur est jetee (E2) 
et n'entrame aucune consequence sur le contexte transactionnel. Dans le 
cas contraire, un evenement transactionnel ROLLBACK (ET) est envoye 
10 vers les systemes externes (40) pour annuler le contexte transactionnel. 
Dans un mode de realisation de invention, Tidentifiant transactionnel (trld) 
est aussitot supprime. 

L'invention va a present etre decrite en. liaison avec les figures 1, 3 et 

4. 

15 La premiere interface (21) de communication permet d'initialiser oj'ne 

transaction pour un service et un utilisateur donne. Elle donne aussi un 
acces a la requete de demasquage (5. 10) de Tidentifiant transactionnel (trid) 
initiee par un element enabler (31). Cette requete (5, 10) permet de retrouver 
la plupart du temps le numero d'identification (Userld) constitue par exemple 

20 du numero MSISDN. II est possible aussi d'effectuer une requete (301) de 
mise a jour du service ou Update, adressee a cette interface (21). Comme 
illustre a la figure 4, la requete (301) de mise a jour Update peut etre 
associee a la realisation concrete de la requete enabler (LOG, SMS, MMS) 
jusqu'a Tutiiisateur abonne a I'offre de service, dans le but de s'assurer de la 

25 bonne livraison du service. La requete Update est par exemple egalement 
associee au contenu de Tinformation qui transite de I'element enabler (31) a 
Tabonne, afin de permettre la verification du contenu du service. 

Dans un mode de realisation de Tinvention. la methode de mise a jour 
Update est emise par un element serveur enabler (31). Elle est constituee 

30 par la mise en etat d'attente de mise a jour concernant la realisation de la 
requete du serveur d'identifiant transactionnel (GIDT). La mise a jour peut 
etre realisee de maniere asynchrone a la realisation de la requete a un 
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La logique interne du moyen serveur d'identifiknt transactlonnel 
(GIDT) realise egalement une m6thode communement ajpelee ERROR (E) 
qui permet de detecler et de signaler la presence djerreur ayant une 
incidence dans le processus selon I'lnvention. Un code d Jrreur (EO) est regu 
par un moyen comparateur veriflant le nombre de reprisis sur erreur. Une 
comparalson (El) est effectu6e entre le nombre de reprisL sur erreur et un 
seuil predetermine. Tant que le seuil n'est pas atteint. I'erreur est jetee (E2) 
■ et n'entraTne aucune consequence sur le contexte transactionnel. Dans le 
cas contraire, un evenement transactionnel ROLLBACK (ET) est envoye 
vers les systemes extemes (40) pour annuler le contexte transactionnel. 
Dans un mode de realisation de I'lnvention. ridentifiant transactionnel (trid) 
est aussitot supprime. 

L'invention va a present etre decrite en liaison avec les figures 1 2 et 

3. 

La premiere interface (21) de communication permet d'initialiser une 
transaction pour un service et un utilisateur donn6. Elle donne aussi un 
acc^s ^ la requete de d6masquage (5. 10) de ridentifiant transactionnel (trId) 
initi^e par un element enabler (31). Cette requete (5, 10) pirmet de retrouver 
la plupart du temps le num^ro d'identification (Userld) conititue par exemple 



requete (301) de 



du numero MSISDN. II est possible aussi d'effectuer une,.„,„..^ „^ 
mise ^ jour du service ou Update, adressee a cette interface" (21^ Comml 
illustre a la figure 3, la requete (301) de mise a jour Update peut etre 
associee a la realisation concrete de la requete enabler (LOG. SMS. MMS) 
jusqu'a rutilisateur abonne a I'offre de service, dans le butL s'assurer de la 
bonne livraison du service. La requite Update est par exemple egalement 
associee au contenu de I'lnformation qui translte de I'element enabler (31) a 
I'abonne. afin de permettre la verification du contenu du serVice.. 

Dans un mode de realisation de I'invention. la methode de mise a jour 
Update est emise par un element seiveur enabler (31). Elle est constitute 
par la mise en etat d'attentb de mise a jour concemant I j realisation de la 
requete du serveur d'Identifiant transactionnel (GIDT). La mise a jour peut 
etre realis6e de maniere asynchrone a la realisation de la requete a un 
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element enabler (31) mais peut conditionner le COMMIT (CT) transactionnel 
de rensemble ou partie de I'offre de service. Par exemple, dans le cas d'un 
enabler (SMS) de messages courts, des messages asynchrones de 
notification de delivrance peuvent etre utilises pour s'assurer que le contenu 
5 a ete delivre a Tutilisateur. 

Le processus selon Tinvention peut aussi bien fonctionner en mode 
Push/MT qu'en mode Pull/MO, remission d'une requete d'ouverture de 
transaction (1) d'au moins un service determine pouvant etre initiee soit par 
un utilisateur. soit par un fournisseur de service (33). Dans rexemple de la 

10 figure 1, c*est le fournisseur (33) qui demande Touverture d'une transaction 
au gestionnaire (GIDT) pour le compte d'un utilisateur represents dans la 
requete par un identifiant (Userld) du type numero de telephone ou tout 
autre identifiant d'utillsateur. Cette requete (1) est adressee en mode Push 
vers la premiere interface de communication (21) du gestionnaire (GIDT)..Ce 

15 dernier precede alors a I'analyse (T) de la requete (1) par rintermediaire.'de 
moyens de gestion et de controle (26, 27) du gestionnaire (GIDT), afin de 
verifier la correspondance du service objet de la requete avec une offre.de 
service repertoriee parmi la pluralite d'offres de services stockees ,en 
memoire (25). Ces moyens de gestion et de controle (26, 27) effectuent 

20 Tanalyse (1') notamment par resolution d'une correspondance entre une 
adresse technique de service notifiee dans la requete (1) d'quverture de 
transaction et une offre de service repertoriee parmi la pluralite de 
descriptions d'offres de service stockees dans la memoire (25) du moyen 
serveur d'identifiant (GIDT). Dans le mode de realisation de la figure 1, une 

25 adresse technique est inseree dans la requete d'ouverture de transaction (1) 
pour decrire le service fourni par le fournisseur (31) a I'origine de la requete 
(1). Cette adresse technique est "resolue" par le gestionnaire (GIDT), et ce 
dernier associe a cette adresse technique un identifiant transactionnel (trid). 
Dans un mode de realisation de I'invention, I'etape d'analyse (V) 

30 comprend une verification par le module de gestion (27) de la 
correspondance des elements serveurs « enablers » (31) designes dans 
I'adresse technique avec une offre de service repertoriee accessible pour 
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I'utilisateur parmi la pluralite d'offres de service et un controle de 
Tautorisation d'ouverture de la transaction par des moyens de controle (26) 
du moyen serveur d'identifiant transactionnel (GIDT), pour le service fourni 
par ces elements serveurs « enablers » (31) et Tutilisateur specifie. en 
fonction notamment de I'identificatlon de I'utilisateur (Userld). L'etape de 
realisation (R) de la transaction utilisant I'identifiant transactionnel opaque 
• (trid) succede a l'etape d'analyse (1') de la requete (1). 

Dans le mode de realisation de la figure 1, la requete d'ouverture de 
transaction (1) emise par le fournisseur de sen/ice (33) concerne un service 
faisant appel a trois elements serveurs « enablers » (LOG, SMS. MMS) 
realisant des sous-transactions (R'). Cette requete (1), adressee a I' interface 
de communication (23) avec les fournisseurs du gestionnaire d'identifiant 
transactionnel (GIDT). peut §tre d6crite de maniere sequentielle avec un lot 
de primitives ouvertes et notifie une identification de I'utilisateur (Userld). 
Dans un autre mode de realisation de I'invention, la requete (1) peut 
concerner au moins un service faisant appel a un ou plusieurs elements 
serveurs « enablers » (31). 

L'etape de realisation (R) de la transaction est initiee par le 
fournisseur de service (33), apres reception de I'identifiant transactionnel 
opaque (trId). Le fournisseur de service (33) effectue une demande a un 
serveur determine (LOG, SMS, MMS) parmi les elements serveurs enablers 
(31), avec I'identifiant transactionnel opaque (trId) en parametre. d'un service 
determine constituant une sous-transaction (R'), comme illustre a la figure 1. 
En reponse a cette demande, I'element serveur enabler determine (LOG, 
SMS, MMS) envoie vers le gestionnaire d'identifiant transactionnel (GIDT) 
une requete (5, 10) de demasquage « unmask » pour autoriser ^ partir de 
I'identifiant opaque (trId) la fourniture d'un numero d'identification (Userld) 
non opaque correspondant a I'identifiant transactionnel opaque (trId). Un 
controle (5', 10') est ensuite realise par les moyens de contrdle (26) du 
moyen serveur d'identifiant transactionnel (GITD) pour verifier si I'element 
serveur determine « enabler» (LOG, SMS, MMS) est autorise ou non pour ce 
service et pour cet utilisateur, de sorte qu'en cas d'autorisation, le numero 
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d'identification (Userld) non opaque est transmis (7, 12) via la premiere 
interface de communication (21) vers Telement serveur determine (LOG, 
SIVIS, IVIMS) pour permettre la realisation de la sous-transaction (R*). 

Dans I'exemple de la figure 1, la premiere sous-transaction (R') 
5 concerne un service de localisation faisant intervenir un serveur de 
localisation (LOG). Gette premiere sous-transaction (R') commence par une 
demande de localisation (4) effectuee par le fournisseur de service (33) et 
adressee au serveur de localisation (LOG) avec I'identifiant de transaction 
(trid) en parametre. Apres avoir re^u le numero d'identification (Userld) non 

10 opaque transmis (7) par le gestionnaire (GIDT), le serveur de localisation 
(LOG) transmet (8) les informations de localisation demandees. au 
fournisseur d'offres de service (31 ). 

Dans le mode de realisation prefere de invention, le gestionnaire ^ 
d'identifiant transactionnel (GIDT) comporte, d'une part un moteur 

15 transactionnel (28) generant des emissions d'evenements transactionnels : 
constitues de Tune ou I'autre des commandes suivantes : BEGIN (ST), 
GOMMIT (GT), ROLLBAGK (ET) et d'autre part d'un moteur de tragabilite ^ 
(29) consignant dans la memoire (25) chaque evenement du moteur 
transactionnel (28) et I'ensemble des informations emises pendant 

20 rutilisation du gestionnaire d'identifiant transactionnel (GIDT). Gomme . 
represente a la figure 1, Tetape d'analyse (1') avec controle d'autorisation > 
pour Touverture de la transaction est immediatement suivie de I'envoi vers 
au moins un systeme externe (40) d'un evenement de debut de transaction,, 
sous la forme d'une commande BEGIN (ST) generee par le moteur 

25 transactionnel (28). La generation de I'evenement de debut de transaction 
est realisee par Tintermediaire de interface de notification des transactions 
(22) du gestionnaire (GIDT). 

Le systeme externe (40) peut consister en un systeme de facturation 
par exemple pour reserver un ticket de facturation. L^etape d'analyse (V) est 

30 egalement suivie d'un enregistrement par le moteur de tragabilite (29) de 
statistiques d'ouverture de service, realise sensiblement au meme moment 
que la generation de la commande BEGIN (ST). Des que I'evenement de 
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debut de transaction a ete envoye vers le systeme externe (40), una sous- 
transaction (R') peut §tre realisee. Le moteur de tragabilite (29) enregistre 
egalement des statistiques (6, 11) a la fin de chacune des sous-transactions 
(R"). Le contexte transactionnel est mis a jour lors de la fin de realisation 
d'une sous-transaction (R'). Naturellement, des systemes du type 
gestionnalres de dialogue, IHM, systemes de paiement a facte ou forfait et 
autres systemes analogues peuvent se greffer sur le moteur transactionnel 
(28). Dans un mode de realisation de I'inventlon, le moteur de tragabilite (29) 
dispose de I'ensemble des informations 6mises par {'utilisation du 
gestionnaire d'identifiant transactionnel (GIDT), par exemple sur le controle 
d'acces qu'il soit positif ou negatif. sur la realisation de I'offre qu'elle soit 
complete ou en cours, etc. 

Dans rexemple de la figure 1 , la deuxidme sous-transaction (R") fait 
intervenir un serveur de messages courts (SMS), le fournisseur de service 
(33) effectuant une demande (4) au serveur (SMS). Le mode de 
communication est analogue au cas susmentionne pour la sous-transaction 
(R') avec le serveur de localisation (LOG). Cette fois, apres avoir regu le 
numero d'identification (Userld) non opaque transmis (12) par le gestionnaire 
(GIDT), le serveur (SMS) transmet (13) les informations de messages courts 
demand^es au fournisseur de service (33). Une troisieme sous-transaction 
fait intervenir un serveur enabler de messages multimedia (MMS). Dans 
I'exemple de cette troisieme sous-transaction, une incoherence est detectee 
par le gestionnaire (GIDT) entre la description de service stockee dans la 
memoire (25) et la demande d'invocation du serveur enabler de messages 
multimedia (MMS). Une telle erreur peut etre detectee par exemple lorsque 
la description du service prevoit I'envoi d'un e-mail. Les deux premieres 
etapes (14, 15) sont analogues aux deux premieres etapes (4, 5) de la 
premiere sous-transaction (R') concernant le serveur de localisation (LOG). 
Puis r.incoherence est detectee lors de I'execution de la m6thode de 
demasquage, comme illustre avec le schema correspondant de la figure 4. 
Le moteur de tragabllite (29) enregistre des informations statistiques (16) 
representatives de I'echec de la transaction. Ensuite, le gestionnaire 
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debut de transaction a ete envoye vers le syst§me exterhe (40),>une sous 
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transaction (R') peut §tre r§alis6e. Le moteur de tragabi 
§galement des statistiques (6, 11) a la fin de chacune des; sous-transactions 
(R'). Le contexte transactionnel est mis a jour lors de la fin de realisation 
d'une sous-transaction (R'). Naturellement, des systemes du type 
gestionnaires de dialogue, IHM, systemes de paiement a 
autres systemes analogues peuvent se greffer sur le mo 
(28). Dans un mode de realisation de I'invention, le moteur de ti-agabilite (29) 
dispose de I'ensemble des informations emises par I'utilisation du 
gestionnaire d'identlfiant transactionnel (GIDT), par exemple sur le controle 



I'acte ou'forfait et 
:eur transactionnel 



I'offre qu'eJIe soit 



d'acces qu'il soit positif ou negatif, sur la realisation de 
complete ou en cours, etc. 

Dans I'exemple de la figure 1, la deuxieme sous-transaction (R'). fait 
intervenir un serveur de messages courts (SMS), le foumisseur de -service 
(33) effectuant une demande (4) au serveur (SMS). Le mode de 
communication est analogue au cas susmentionne pour la sous-transaction 
(R') avec le serveur de localisation (LOG). Cette fois, aDres avoir regu le 
num6ro d'identification (Userld) non opaque transmis (12) Dar le gestionnaire 
(GIDT). le serveur (SMS) transmet (13) les informations de messages;. courts 
demandees au foumisseur de service (33). Une troisiemi sous-transaction 
fait intervenir un serveur enabler de messages multimedia (MMS). Dans 
I'exemple de cette troisieme sous-transaction, une incoherence est detectee 
par le gestionnaire (GIDT) entre la description de service stockee dans la 
memoire (25) et la demande d'invocation du serveur enaaler de messages 
multimedia (MMS). Une telle erreur peut etre detectee pa - exemple lorsque 
la description du service prevoit I'envoi d'un e-mail. Les deux premieres 
etapes (14, 15) sont analogues aux deux premieres etapes (4, 5) de la 
premiere sous-transaction (R') concernant le serveur de localisation (LOG). 
Puis I'incoh^rence est detectee lors de I'execution de la methode de 
d6masquage, comme illustre avec le schema correspondant de la figure 3. 
Le moteur de tragabilite (29) enregistre des informations statistiques (16) 
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d'identifiant transactionnel (GIDT) envoie. via la premiere interface de 
communication (21), une reponse negative (17) a l'§lement serveur enabler 
(IVIIVIS). Ce dernier (MMS) notifie au fournisseur d'offres de service (31) le 
refus d'autorisation (18) d'envoi de message court multimedia. Pour finir. le 
gestionnaire d'identifiant transactionnel (GIDT) emet, via I'interface de 
notification des transactions (22), un evenement transactionnel de type fin de 
. reprise ROLLBACK (ET) pour signifier au systeme externe (40) que le 
service de bout en bout a echoue, le nombre de reprise de la transaction sur 
erreur etant depasse. Get evenement ROLLBACK (ET) notifie que la 
transaction est annulee. Dans un mode de realisation de I'invention, des 
donnees fournies avec I'evenement transactionnel ROLLBACK (ET) sont 
transmises a un gestionnaire de dialogue et permettent de facturer ou non le 
service. 

L'invention va ^ present §tre decrite en liaison avec les figures 4 et 5. 
La figure 4 repr^sente les methodes avec des logiqued d'^tats 
associees aux interactions entre les elements serveurs enablers (31) et le 
gestionnaire (GIDT). La methode de masquage dite Mask du gestionnaire 
d'identifiant transactionnel (GIDT) retrouve dans un premier temps (202) les 
informations de I'offre cibl§e (203) pour fldentifiant (Userld) a partir de 
I'adresse technique (201) et de la pluralite d'offres de service stockee dans 
. la mernoire (25). Ensuite, la methode Mask controle I'acces (204) d'un 
utilisateur abonne a I'offre de service (203) et emet soit un refus d'acces 
(R1) soit declenche la methode Start (S). 

La methode de demasquage dite Unmask du gestionnaire d'identifiant 
transactionnel (GIDT) retrouve dans un premier temps (205) les informations 
de I'offre ciblee (206) a partir de donnees representatives de I'adresse 
technique et I'identifiant transactionnel (trid) et a partir de ladite pluralite des 
offres. Ensuite, comme illustre ^ la figure 4, la methode Unmask contrdle 
I'acces (207) d'un partenaire (33) a I'element serveur enabler (LOG. SMS. 
MMS) et verifie (208) que la requ§te faite a I'element serveur (LOG, SMS, 
MMS) est en correspondance avec le contexte actuel de la transaction. Puis, 
dans le cas oCi une mise ^ jour est necessaire, la methode Unmask se 
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d'identifiant transactionnel (GIDT) envoie. via la premiere interface de 
communication (21), una r^ponse negative (17) a I'element serveur enabler 
(IVIIVIS). Ce demier (MMS) notlfie au foumisseur d'offres de service (31) le 
refus d'autorisation (18) d'envoi de message court multimedia. Pourfinir, le 
gestionnaire d'identifiant transactionnel (GIDT) emet. ^la rinterface de 
notification des transactions (22), un evenement transactio inel de type fin de 
reprise ROLLBACK (ET) pour signifier au systeme externe (40) que le 
service de bout en bout a echoue, le nombre de reprise de la transaction sur 
erreur etant depasse. Get evenement ROLLBACK (ET) notifie que la 
transaction est annulee. Dans un mode de realisation de I'invention. des 
donnees fournies avec i'evenement transactionnel ROLLBACK (ET) sont 
transmises a un gestionnaire de dialogue et permettent de facturer ou non le 
service. 

L'invention va a present etre decrite en liaison avec les figures 3»et 4. 
La figure 3 represente les methodes avec des logiques d'Stats 
associees aux interactions entre les Elements sen/eurs e iablers (31) et le 
gestionnaire (GIDT). La methode de masquage dite Mask du gestionnaire 
d'identifiant transactionnel (GIDT) retrouve dans un premier temps (202) les 
informations de I'offre clblee (203) pour I'identifiant (Us'erld) a partir de 
I'adresse technique (201) et de la pluralite d'offres de servjice stock6e dans 
la memoire (25). Ensuite, la methode Mask controle I'acces (204) d'un 
utilisateur abonne a I'offre de service (203) et emet soit 
(R1 ) soit declenche la methode Start (S). 

La methode de demasquage dite Unmask du gestionnaire d'identifiant 
transactionnel (GIDT) retrouve dans un premier temps (205I les informations 
de I'offre clbl§e (206) a partir de donn§es representatives de I'adresse 
technique et I'identifiant transactionnel (trid) et a partir de ledite plurality des 
offres. Ensuite. comme illustr6 ^ la figure 3. la methode Unmask controle 
I'acces (207) d'un partenaire (33) a I'element serveur enabler (LOG. SMS. 
MMS) et v6rifie (208) que la requete falte a I'element serveur (LOG, SMS, 
MMS) est en correspondance avec le contexte actuel de la t'ransaction. Puis, 
dans le cas ou une mise a jour est necessaire, la methLde Unmask se 



un refus d'acces 



1 er depot 

22 



Modifiee le 11/08/03 



poursuit en signalant a I'element serveur enabler (LOG, SMS. MMS) que le 
gestionnaire d'identifiant transactionnel (GIDT) est en attente d'une mise a 
jour, retourne (210) le numero MSISDN ou Identification (Userld) analogue 
associe a I'identifiant transactionnel opaque (trid), se met en attente (211) de 
la mise a jour Update, puis verifie (302) que la mise a jour regue contlent les 
informations necessaire pour la realisation de I'offre pour soit emettre une 
methode Completed (C) soit une methods Error (E). Un refus d'acces (R2) 
est notifies lorsque ['acces n'a pas ete autorlse lors du controle (207). Dans le 
mode de realisation de la figure 4, une etape de controle (209) de mise a 
jour intervlent apres I'etape de verification (208), pour activer directement la 
realisation de I'offre avec une methode Completed (C) dans le cas ou la 
mise a jour Update n'est pas necessaire. 

La figure 5 presente les m§thodes de communication entre un 
fournisseur de service (33) et le gestionnaire- d'identifiant transactionnel 
(GIDT) servant a I'ouverture et a la fermeture d'une transaction. La methode 
OpenTransaction est emise par un fournisseur de service a valeur ajoutee 
(33) vers I'interface pour fournisseurs (23) du gestionnaire (GIDT) pour 
controler I'acces (100) d'un partenaire (33) ^ un abonne de I'operateur et 
produire soit un refus d'acces (R3) soit declencher une methode Start (S). La 
methode CloseTransaction , emise par un fournisseur (33) vers I'interface 
pour fournisseurs (23) du gestionnaire (GIDT), genere un evenement 
permettant de debloquer Tattente « TimeOut » de la logique du gestionnaire 
d'identifiant transactionnel (GIDT). 

L'invention va a present etre decrite en liaison avec la figure 6. 
En mode Pull/MO. la cinematique de livraison d'un service presente 
quelques differences par rapport a un fonctionnement en mode Push. La 
figure 6 iilustre le cas. d'un service decrit dans la memoire (25) comme etant 
compose d'une demande de localisation suivie de I'envoi d'un message 
court SMS. Comme pour le mode Push, le deroulement du service, 
notamment les invocations vers les enablers, est renseigne dans la 
description du service et I'adresse technique du fournisseur d'offres de 
service (31) est connue par le gestionnaire (GIDT). 
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poursuit en signalant a Telement serveur enabler (LOG, SMS, MMS) que le 
gestionnaire didentifiant transaction nel (GIDT) est en attente d'une mise a 
jour, retourne (210) le numero MSISDN ou identification 
associe a ridentifiant transactionnel opaque (trld). se met 

5 la mise ^ jour Update, puis verifie (302) que la mise a jour regue contient les 
informations necessaire pour la realisation de Toffre poiir soit eme'ttre une 
methode Completed (C) soit une methode Error (E). Un 
est notifie lorsque Tacces n'a pas ete autorise lors du con 
mode de realisation de la figure 3, une etape de contro 

10 jour intervient apres I'etape de verification (208), pour ac 
realisation de I'offre avec une methode Completed (C) 
mise a jour Update n'est pas necessaire. 

La figure 4 presente les methodes de communication entre un 
foumisseur de service (33) et le gestionnaire d'identifiant transaictionnel 

15 (GIDT) servant a I'ouverture et a la fermeture d'une transaction. La methode 
OpenTransaction est emise par un fournisseur de service a valeur ajoutee 
(33) vers {Interface pour fournisseurs (23) du gestionnaire (GIDT) pour 
controler Tacces (100) d'un partenaire (33) a un abonnje de I'operateur et 
produire soit un refus d'acces (R3) soit declencher une methode Start (8). La 

20 methode CloseTransaction , emise par un fournisseur (33) vers I'ihterface 
pour fournisseurs (23) du gestionnaire (GIDT), genere un evenement 
permettant de debloquer I'attente « TimeOut » de la logique du gestionnaire 
d'identifiant transactionnel (GIDT). 

L'invention va a present §tre decrite en liaison avec la figure 5. 

25 En mode Pull/MO, la cinematique de livraison d'un service presente 
quelques differences par rapport a un fonctionnement jen mode Push. La 

i 

figure 5 illustre le cas d'lin service d6crit dans la memoir^ (25) comme etant 
compose d'une demande de localisation suivie de renvoi d'un message 
court SMS. Comme pour le mode Push, le deroulement du service, 
30 notamment les invocations vers les enablers, est renseigne dans la 
description du service et I'adresse technique du fournisseur d'offres de 
service (31 ) est connue par le gestionnaire (GIDT). i 
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Tout d'abord. une demande de service d'un utilisateur doit §tre 
envoyee a un element serveur enabler pour les messages (SIVIS), par 
I'intermediaire d'un message MO transmis a partir du telephone mobile de 
I'utilisateur. L'element sen/eur enabler (SMS) intercepte alors la demande de 
service issue de I'utilisateur. Le grand compte de I'enabler (SMS) etant 
assocle a une adresse technique du service, I'enabler (SMS) demande done 
I'ouverture (O) d'une transaction au gestionnaire d'identifiant transactlonnel 
(GIDT) pour I'utilisateur et service concerne. Cette requete d'ouverture (O), 
adressee a la premiere interface de communication (21) du gestionnaire 
(GIDT), est decrite de maniere sequentielle avec un lot de primitives 
ouvertes et notifie une identification de I'utilisateur (Userld). Une analyse (1') 
de la requete (O) est alors effectuee et, en cas d'autorisation par les moyens 
de contrdle (26) du gestionnaire (GIDT), une commande BEGIN (ST) est 
generee par le moteur transactlonnel (28) pour notifier un 6v6nement de 
debut de transaction au systeme externe (40). 

Un identifiant de transaction (trid) correspondant au service et a 
I'utilisateur est retoume (3') a I'enabler grand compte de messages courts 
(SMS). Ensuite, le fournisseur de service a valeur ajoutee (33) regoit (3") la 
requete utilisateur sous la forme d'un message court envoye a partir de 
I'enabler (SMS), sans toutefois connaitre I'identlte exacte de celui-cr car seul 
I'identifiant transactionnel (trId) lui est fourni. Les sous-transactions (R") 
peuvent alors etre realisees de la meme fagon que dans le mode de 
communication en mode Push (figure 1). A la fin de la derniere sous- 
transaction (R"), le gestionnaire d'identifiant transactionnel (GIDT) detecte le 
bon achevement de la realisation (R) de la transaction pour le service. II 
notifie au systeme externe (40) que le service a ete delivre de bout en bout 
pour I'utilisateur concerne, par g6n6ration d'un evenement transactionnel 
COMMIT (CT). 

Un des avantages du precede selon {'invention est de permettre de 
gerer une session de service a un abonne utilisant plusleurs enablers du 
reseau de I'operateur, en generant des ^venements sur I'avancement de sa 
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realisation, ce qui permet par exemple de facturer un service en fonction du 
nombre de sous-transactions reellement effectuees. 

Un autre des avantages de Tinvention par rapport aux techniques 
existantes est que Toperateur peut garantir la confidentialite des donnees de 
5 Tutiiisateur vis-a-vis des fournisseurs de service. 

II doit etre evident pour les personnes versees dans Tart que la 
presente invention permet des modes de realisation sous de nombreuses 
autres formes specifiques sans Teloigner du domaine d'application de 
['invention comme revendique. Par consequent, les presents modes de 
10 realisation doivent etre consideres a titre d'illustration, mais peuvent etre 
modifies dans le domaine defini par la portee des revendications jointes, et 
rinvention ne doit pas etre limitee aux details donnes ci-dessus. 
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ANNEXE 

Adresse technique : chaine de caracteres decrivant pour un enabler 
un service donne. Une adresse technique peut §tre un nnessage court ou 
short-code dans le cas des medfas SMS et GD (exemple « 2222 »), ou une 
adresse URL dans le cas du media Wap (exemple : http://wap.sfr.net V La 
chaine de caracteres constituant I'adresse technique peut aussi se terminer 
par le caractere *. 

CAMEL : Customized Applications for Mobile network Enhanced 
Logic, (nom generique d'applications pour les mobiles) 

DTD : Definition Type de Document 

GD : Gestionnaire de Dialogue 

GID : Gestionnaire d'Identifiant 

GIDT : Gestionnaire d'Identifiant Transactionnel 

GO : Gestionnaire d'Offre 

LOG enabler : Plate-forme de localisation 

SMS enabler: Plate-forme permettant d'envoyer des messages 

courts 

MMS enabler : Plate-forme pour envoyer des messages multimedia 

IHM : Interaction Homme - Machine 

MO / MT : Mobile Originated / Mobile Terminated 

MS-ISDN: Mobile Station - Integrated Services Digital Network. C'est 
le numero d'appel du telephone mobile. 

OSA : Open Service Access (definit une interface avec un reseau de 
radiotelephonie mobile) 

PARLAY : equivalent du OSA pour le reseau fixe. 

UIT : Union Internationale des Telecommunications 

VASP : Value Added Service Provider 

WAP : Protocole d^application sans fil (Wireless Application Protocol) 
WAP-server : serveur WAP pouvant etre utilise par les telephones 
mobiles via une passerelle WAP (WAP-gateway) traduisant dans un format 
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compatible avec Internet les informations transmises sur un reseau mobile et 
qui est capable d'effectuer la conversion inverse 

XML : extensible Mark-up Language. Meta langage proche du HTML. 
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REVENDICATIONS 

1. Procede de controle avec gestion d'un identifiant opaque 
d'utilisateur de la livraison complete d'un service utilisant au molns un 
serveur (31), caracterise en ce qu'il est realise par I'intermediaire d'un moyen 
serveur d'identifiant transactionnel (GIDT) stockant dans une memoire (25) 
pour chaque utilisateur une description d'une plurality d'offres de service 
souscrite par I'utilisateur aupres de fournisseurs de service a valeur ajoutee 
(33), ledit moyen serveur d'identifiant transactionnel (GIDT) comprenant un 
module de gestion (27) permettant d'associer a un utilisateur ou groupe 
d'utilisateurs et a au moins un service determine un identifiant transactionnel 
opaque (trid), ledit procede comprenant les etapes suivantes : 

- Emission par un element serveur « enabler» ayant intercepte une 
demande de service d'un utilisateur ou par un desdits fournisseurs 
de service (33) d'une requete d'ouverture de transaction (1) d'au 
moins un service falsant appel a au moins un element serveur 
«enabler» detemnine (31) realisant des sous-transactions (R'), 
cette requete (1) etant decrite de maniere sequentielle avec un lot 
de primitives ouvertes et adressee a une interface de 
communication (21, 23) du moyen sen/eur d'identifiant 
transactionnel (GIDT) et notifiant une identification de I'utilisateur 
(Userld). 

- analyse (1') de la requete et generation d'un identifiant 
transactionnel opaque (trId) par des moyens de gestion et de 
controle (26, 27) du serveur d'identifiant transactionnel (GIDT), puis 

- une etape de realisation (R) de la transaction utilisant I'identifiant 
transactionnel opaque (trId). 

2. Proc6de selon la revendication 1, caracterise en ce que I'etape 
d'analyse (1') comprend une verification par le module de gestion (27) de la 
correspondance des elements serveurs « enablers » determines (31) avec 
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une offre de service repertoriee accessible pour I'utilisateur parmi la pluralite 
d'offres de service et un controle de I'autorisation d'ouverture de la 
transaction par des moyens de controle (26) du moyen serveur d'identifiant 
transactionnel (GIDT), pour le service fourni par les elements serveurs 
5 « enablers » (LOG, SMS, MMS) et Tutilisateur specifie. en fonction 
notamment de Tidentification de rutilisateur (Userld). 

3. Precede salon la revendication 1 ou 2, caracterise en ce que 
I'etape de realisation (R) de la transaction est initiee par un fournisseur de 
service a valeur ajoutee (33) ayant regu I'identifiant transactionnel opaque 

10 (trid) de la part du moyen serveur d'identifiant transactionnel (GIDT), le 
fournisseur de service (33) effectuant une demande a un element serveur 
enabler determine (31), avec I'identifiant transactionnel opaque (trId) en 
parametre, d'un service determine constituant une sous-transaction, pfour 
declencher en reponse sur Telement serveur enabler determine (LOG, SMS. 

15 MMS) renvoi vers le serveur d'identifiant transactionnel (GIDT) d-une 
requete (5) de demasquage « unmask » permettant a partir de ridentifiant 
opaque (trId) la fourniture d'un numero d'identification (Userld) non opaque 
correspondant a I'identifiant transactionnel opaque (trId), un controle (5', 10') 
etant ensuite realise par les moyens de controle (26) du moyen serveur 

20 d'identifiant transactionnel (GITD) pour verifier si I'element serveur determine 
« enabler» (LOG, SMS, MMS) est autorise ou non pour ce service et pour 
cet utilisateur, de sorte qu'en cas d'autorisation, le numero d'identification 
(Userld) non opaque est transmis (7, 12) via une interface de communication 
. dite interface enabler (21) vers I'element serveur determine (31) pour 

25 permettre la realisation de la sous-transaction (R'). 

4. Procede selon Tune quelconque des revendications 1 a 3, 
caracterise en ce que I'identifiant transactionnel (trId), compose d'au 
maximum 15 digits, est conforme au plan de numerotation UIT-T E-164 et le 
numero d'identification (Userld) non opaque est le numero MSISDN. 

30 5. Procede selon Tune quelconque des revendications 1 a 4, dans 

lequel le moyen serveur d'identifiant transactionnel (GIDT) comporte, d'une 
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part un moteur transactionnel (28) generant des emissions d'6v6nements 
transactionnels constitues de Tune ou I'autre des commandes suivantes : 
BEGIN (ST), COMMIT (CT), ROLLBACK (ET) at d'autre part d'un moteur de 
tragabllit6 (29) consignant dans la memoire (25) cheque evenement du 
moteur transactionnel (28) et I'ensemble des Informations emises pendant 
I'utillsation du moyen serveur d'identifiant transactionnel (GIDT). 

6. Precede selon I'une quelconque des revendlcations 1 a 5, 
caracterise en ce que Tidentifiant transactionnel opaque (trid) est envoye (3) 
au fournlsseur d'offres de service (31) apres la memorisation dans la 
memoire (25) du moyen serveur d'identifiant transactionnel (GIDT) d'un 
contexte transactionnel indiquant notamment : 

- un numero d'ldentification (Userld) de I'utilisateur. 

- I'identifiant transactionnel (trId), 

- I'offre associee a la transaction, 

- I'etat d'avancement de la transaction pour I'offre associee a celle-ci. 

7. Precede selon la revendication 6, dans lequel I'envoi (3) de 
I'identifiant transactionnel opaque (trId) au fournisseur d'offres de service 
(31) est precede en outre d'une generation d'un evenement transactionnel 
representatif d'un debut de transaction vers au moins un systeme externe 
(40), par I'intermediaire d'une seconde interface de communication du 
moyen serveur d'identifiant dite interface de notification des transactions 
(22). 

8. Procede selon la revendication 7, dans lequel la generation d'un 
evenement transactionnel representatif d'un debut de transaction vers au 
moins un systeme externe (40) s'effectue par une commande BEGIN (ST) 
generee par un moteur transactionnel (28) du moyen serveur d'identifiant 
transactionnel (GIDT). 

9. Procede selon la revendication 7 ou 8, dans lequel le moyen 
serveur d'identifiant transactionnel (GIDT) transmet, depuis I'interface de 
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notification des transactions (22) a au moins un systeme externe,(40), des 
donnees representatives de la realisation complete de Toffre par une 
commande COMMIT (CT) generee par le moteur transactionnel (28) pour 
indiquer au systeme externe (40) par exemple de facturation que la 
5 transaction est completement realisee. 

10. Procede selon Tune quelconque des revendications 7 a 9, dans 
lequel le moyen serveur d'identifiant transactionnel, emet, via I'interface de 
notification des transactions (22), un evenement transactionnel de type fin de 
reprise ROLLBACK pour signifier a au moins un systeme externe (40) que le 

10 nombre de reprise de la transaction sur erreur est. depasse et que la 
transaction est annulee pour fournir des donnees a un gestionnaire de 
dialogue et pour facturer ou non le service. 

11. Procede selon Tune quelconque des revendications 1 a 10, dans 
lequel les moyens de gestion et de controle (26, 27) du serveur d'identifiant 

15 transactionnel (GIDT) effectuent Tanalyse (1') de la requete d'ouverture de 
transaction notamment par resolution d'une correspondance entre une 
adresse technique de service notifiee dans la requete (1) d'ouverture de 
transaction et une offre de service repertoriee parmi la pluralite^ de 
descriptions d'offres de service stockees dans la memoire (25) du moyen 

20 serveur d'identifiant transactionnel (GIDT). 

12. Procede selon Tune quelconque des revendications 1 a 11, dans 
lequel la memoire du moyen serveur d'identifiant transactionnel (GIDT) 
stocke des descriptions d'offres de service validees par lesdits fournisseurs 
(31), saisies par Tintermediaire d'une troisieme interface de communication 

25 dite interface de fourniture des descriptions de service (IFDS). 

13. Procede selon Tune quelconque des revendications 1 a 12, dans 
lequel la description d'une offre de service comprend des donnees formulees 
dans un meta langage ou forme equivalente permettant aux moyens de 
controle de moyen serveur d'identifiant de controler le bon deroulement du 

30 service et d'en detecter le debut et la fin. 
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14. Procede selon I'une quelconque des revendications 1 ^ 13, dans 
lequel le moyen serveur d'identifiant transactionnel (GIDT) comporte une 
interface de communication supplementaire (23) destin^e aux foumisseurs 
de services a valeur ajoutee, la premiere interface (21) 6tant destlnee aux 
elements serveurs (31 ). 

15. Precede selon I'une quelconque des revendications 1 d 14, dans 
lequel le moyen serveur d'identifiant transactionnel (GITD) comporte une 
logique interne r^alisant les methodes suivantes : Start (S), Completed (C), 
Error (E). Mask, Unmask, Update, OpenTransaction, CloseTransaction. 

16. Precede selon la revendication 15, dans lequel la methode Start 
(S) du moyen serveur d'identifiant transactionnel (GIDT) genere (S1) un 
identifiant transactionnel (trid), cree (S2) un contexte transactionnel en 
memoire, genere un evenement transactionnel de type BEGIN (ST) et 
retourne i'identifiant transactionnel (trId) au fournisseur d'offres de service 
(31). 

17. Precede selon la revendication 15 ou 16, dans lequel la methode 
Completed (C) du moyen serveur d'identifiant transactionnel (GIDT) 
determine par un test (CI) si une sous-transaction (R') de la transaction a 
ete realisee (CO), modifie (C2) en consequence le contexte transactionnel, 
determine, en scrutant la description de I'offre (C3) s il est necessaire que le 
moyen serveur d'identifiant transactionnel (GIDT) attende (C5) un 
evenement exterieur, positionne la logique soit en attente d'un temps ecoule 
« TimeOut » soit d'une fermeture de transaction « CloseTransaction », 
verifie (C4) si la transaction est achevee et genere un evenement 
transactionnel de type COMMIT (CT). 

18. Precede selon I'une quelconque des revendications 15 ^ 17, dans 
lequel la methode Error (E) du moyen serveur d'identifiant transactionnel 
(GIDT) verifie si le nombre de reprise sur erreur est depasse et dans 
I'affirmative gen6re un evenement transactionnel de type ROLLBACK (ET). 
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19. Precede selon Tune quelconque des revendications 15 a 18, dans 
lequel la methode Mask est emise par un element serveur « enabler » pour 
retrouver (202) les infornnations de Toffre ciblee (203) a partir de Tadresse 
technique (201) et de ladite pluralite d'offres, controler Tacces (204) d'un 

5 utilisateur abonne a I'offre de service et emettre soit un refus d'acces (R1) 
soit declencher la methode Start (S). 

20. Precede selon Tune quelconque des revendications 15 a 19, dans 
lequel la methode Unmask est emise par un element serveur « enabler » 
pour retrouver (205) les informations de I'offre ciblee (206) a partir de 

10 donnees representatives de I'adresse technique et Tidentifiant transaction nel 
(trld) et a partir de ladite pluralite des offres, controler I'acces (207) d'un 
fournisseur (33) partenaire a I'element serveur « enabler » (31), verifier (208) 
que la requete faite a Telement serveur est en correspondance avec le 
contexte actuel de la transaction et signaler a I'element serveur (31) que le 

15 moyen serveur d'identifiant transactionnel (GIDT) est en attente d'une mise a 
jour, retourner (210) le numero MSISDN associe a Tidentifiant transactionnel 
opaque (trid), se mettre en attente (211) de la mise a jour, puis verifier (302) 
que la mise a jour regue contient les informations necessaires pour la 
realisation de I'offre pour soit emettre une methode Completed (C) soit une 

20 methode Error (E). 

21. Procede selon Tune quelconque des revendications 15 a 20, dans 
lequel la methode Update est emise par un element serveur « enabler » et 
constituee par la mise en etat d'attente (211) de mise a jour concernant la 
realisation de la requete du serveur d'identifiant transactionnel (GIDT). 

25 22. Procede selon Tune quelconque des revendications 15 a 21, dans 

lequel la methode OpenTransaction est emise par un fournisseur de services 
a valeur ajoutee pour controler I'acces (100) d'un partenaire a un abonne de 
I'operateur et produire soit un refus d'acces (R3) soit declencher une 
methode Start (S). 
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23. Precede selon I'une quelconque des revendications 17 a 22, dans 
lequel la methode CloseTransactlon est emise par un fournisseur de 
services a valeur ajout6e (33) et g§nere un evenement permettant de 
debloquer I'attente « TimeOut » de la logique du moyen serveur d'identifiant 
transactlonnel (GIDT). 
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